As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Modern information handling systems support execution of a number of different types of software such as, for example, operating system software, gaming applications, social networking programs, document management software, and so on. The companies supplying one or more types of such software are increasingly switching to the Continuous Integration/Continuous Development (CI/CD) model of software design and deployment. The CI/CD is a software development methodology that relies on producing, qualifying, and deploying software builds and artifacts in real time as the program code is created by the software development team. As used herein, the term “build” refers to a software development process that converts source code into executable binaries or artifacts. Thus, the term “artifact” refers to a binary or other output of a build process. In the discussion herein, the terms “package” and “artifact” may be used interchangeably.
Many companies switching to the CI/CD model typically require that the software released to the customer (or end user) be retained for certain periods of time so as to be able to procure it in case of some legal or audit challenge. Typical retention policies for customer-supplied software range from 2 to 10 years. Currently, retention policies are implemented based on a software package's age or type. For example, a software package may be retained for a specific time period based on when the package was built. In case of a package type-based retention, a “Dev” (Development) build package may be retained for 14 days, a “Release” build package may be retained for 365 days, and so on. In the discussion herein, the term “retention policy” refers to a process for determining which artifacts to keep and which to delete.